Should moderator view be it's own parameter instead of one of the listing types? I can see Local and All making sense with it, but what would it mean to have moderator view and Subscribed at the same time? I would think that a moderator of a community would always be following that community, so having both selected seems redundant.

Should moderator view be it's own parameter instead of one of the listing types? I can see Local and All making sense with it, but what would it mean to have moderator view and Subscribed at the same time? I would think that a moderator of a community would always be following that community, so having both selected seems redundant.

You're right it would probably make more sense if moderator view was just another listing type (in appearance for the user). Listing type "all" would be applicable at all times but it will make for some ugly code in the listing type selector and home page. Besides, someone might actually want to differentiate between moderator view for local and all communities and unsubscribe from communities they consider themselves not to be very involved in moderating.

A compromise might be automatically seeing the listing type to all when moderator view of selected but I'm not sure that wouldn't cause frustrations for some users. Let me know which solution you prefer.

Another problem I just noticed now: the moderator view button should probably be hidden when only viewing comments, right?

Another problem I just noticed now: the moderator view button should probably be hidden when only viewing comments, right?

Not necessarily. Comments are content that will need moderation just as much as posts will. As to the rest of your response, I'd like to get some more input on this one.

cc @dessalines @Nutomic @alectrocute @jsit @lionirdeadman

Its up to you whether its a part of the listing_type button group, or separate. Its technically possible to be a mod of non-local communities, so maybe separate is better, but either way works for me.

Another problem I just noticed now: the moderator view button should probably be hidden when only viewing comments, right?

Unfortunately we didn't add moderator_view to comment_view.rs, but @SleeplessOne1917 is correct, and it should be added, since comments also need a moderation view. We don't need to wait on it for this PR, but @biosfood could you do a PR to the lemmy back-end to add that?

I can certainly add moderator view support for comments to the Lemmy backend. I should be able to open a PR sometime next week but don't count on it for this one here.

Since the moderation view currently is implemented as an additional parameter in the get posts method, I'd say it should be exposed to the user as such with its own toggle switch as I implemented it right now.

I think it should be a listing type because if I click that button, I would want it to be all the communities I moderate regardless of local vs all vs subscribed. It's ultimately a way to filter the feed, not a different type of option.

Comments should be a possible view with moderation actions possible of course.

Since the moderation view currently is implemented as an additional parameter in the get posts method, I'd say it should be exposed to the user as such with its own toggle switch as I implemented it right now.

I actually think that the API should be using the same param as the other listing types.. making it its own thing just complicates the API needlessly as the response is the same as any other view.

IMO the API in general is not a good indication of how the UI should be made and it is often too inflexible - often giving too much information or too little - to actually experiment with the UI.

As the consesus seems to be that moderator view should just be a listing type, I will open a PR for the lemmy backend and js client to implement those changes. Keeping this PR as draft until then.

With the backend changes merged, this is now what the selector looks like:

The ModeratorView option is only available, if the user moderates at least one community to avoid confusion.

LemmyNet/lemmy-js-client@973b255 has added some more backend api changes that have built up over some time. The tests won't run clean before those issues are fixed (happens in yarn lint, mostly type problems).

Things that would need to be changed:

• When deleting an account, ask the user weather all their content should be removed as well (src/shared/components/person/settings.tsx:1289:71). Pass false as a default for now? I could open another pull request for that or should I do this here?
• When adding a new Admin, a local user Id is required but the contexts where a button for adding an admin exist (comment view, person view) only provide a user id. What is the "right" way to get a local user id in this context?

@dessalines I have now fixed 3 of the linting errors I knew how to approach. There are 2 more I need some guidance on fixing though, both of them stemming from LemmyNet/lemmy@6047257:

src/shared/components/comment/comment-node.tsx:1494:7 - error TS2345: Argument of type '{ person_id: number; added: boolean; auth: string; }' is not assignable to parameter of type 'AddAdmin'.
Object literal may only specify known properties, and 'person_id' does not exist in type 'AddAdmin'.
1494 person_id: i.commentView.creator.id,

AND:

src/shared/components/post/post-listing.tsx:1690:7 - error TS2345: Argument of type '{ person_id: number; added: boolean; auth: string; }' is not assignable to parameter of type 'AddAdmin'.
Object literal may only specify known properties, and 'person_id' does not exist in type 'AddAdmin'.
1690 person_id: i.postView.creator.id,

Both of those are buttons to add another admin to the instance. The new api needs a Local user id to do this.
IF the local user id is equal to the person id of a user, one can just replace the key to be "local_user_id: i.????View.creator.id". Would that be ok or will it break everything? Let me know so I can fix the problem soon.

Apologies, that's an issue with our back-end I'll try to fix and get out an update for lemmy-js-client soon. AddAdmin should really be using the person_id.

@biosfood Okay new lemmy-js-client is deployed that should be good: 0.19.0-rc.7

Thx!